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INTEGRATED PROXY INTERE\CE FOR 
WEB BASED TELECOMMUNICATION 
TOLL-FREE NETWORK MANAGEMENT 

USING A NETWORK MANAGER FOR 
DOWNLOADING A CALL ROUTING TREE 
TO CLIENT 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

The following patent application is based on and claims 
the benefit of U.S. Provisional Patent Application Ser. No. 
60/060,655, filed Sep. 26, 1997. 

HELD OF THE INVENTION 

The present invention relates generally to information 
delivery systems and, particularly, to a novel, WWW/ 
Internet-based, telecommunications network management 
service for customers of a telecommunications service pro- 
vider. 

BACKGROUND OF THE INVENTION 

Telecommunications service entities, e.g., MCI, AT&T, 
Sprint, and the like, presently provide for the presentation 
and dissemination of customer account and network data 
management information to their customers predominantly 
by enabling customers (clients) to directly dial-up, e.g., via 
a modem, to the entity's application servers to access their 
account information, or, alternately, via dedicated commu- 
nication lines, e.g., ISDN, T-1, etc., enabling account infor- 
mation requests to be initiated through their computer work- 
station running, for example, a Windows-based graphical 
user interface. The requests are processed by the entity's 
application server's, which retrieves the requested customer 
information from one or more databases, processes and 
formats the information for downloading to the client's 
personal computer, or more primitively, a 3270 dumb ter- 
minal or a low-end workstation. 

Telecommunications service providers that offer 800/8xx 
toll-free network service to their customers currently pro- 
vide some type of user interaction to manage their 800/8xx 
network call routing plans. These plans may be pre-arranged 
and activated either by customer initiation, i.e., dial-up with 
a user access code and identification number, or, activated 
automatically at some prearranged time according to a 
prearranged schedule. For example, a customer may have a 
routing plan designed for "normal" conditions and other 
plans for special conditions, e.g., weekend, holiday, 
promotions, etc, which may be automatically activated. 
Additional enhanced toll-free number management features 
are currently available to customers. For instance, customers 
can add, change or delete their enhanced routing trees or 
routing plans in near-real time for their toll-free numbers, for 
example, to respond to traffic conditions, emergencies etc. 

The assignee of the present invention, MCI, currently 
provides an MCI Service View ("MSV") product line that 
provides its business customers with Windows-based client- 
server applications including an 800-Network Manager 
("800NM") which is a PC- Windows based GUI to MCFs 
Network Control System ("NCS"). Particularly, NCS is used 
to perform enhanced routing on MCI's network for special 
service calls. The legacy order entry system for NCS is 
referred to as Network Capabilities System ("NetCap"). 
Orders for a customer's routing features for that customer's 
SOO/Sxx traffic are entered into NetCap which processes the 
order (edits, validates, logs) and submits orders to a Service 



^4,661 Bl 

2 

Control Manager ("SCM") which then formats and distrib- 
utes orders to each of three redundant data access points 
("DAPS") which implements the plan orders at the network 
switches. Once an order is implemented on the DAPS, calls 

5 to the customer's SOO/Sxx number are processed with the 
features specified in the order. 

Particularly, NetCap is a mainframe MVS system that 
implements an on-line subsystem for accepting orders for 
toll-free and VNET routing plans. It also has a background- 

10 processing subsystem that takes these orders, processes 
them, stores them in a database, and feeds orders to SCM. 
Currently, there are three methods for accessing NetCap: a 
direct 3270 terminal connection for internal MCI users 
which provides access to 100 percent of NetCap' s functions; 

15 a PC-based 3270 terminal emulation program that utilizes 56 
kbps dial-up access to a majority of NetCap functions; and, 
a PC-based Windows application entitled "800NM", written 
in C++, for example, which enables customers to implement 
and configure routing plans for toll free and virtual networks 

20 (VNET) via the existing MCI Serv^ice View (MSV) infra- 
structure comprising a private network of routers and pro- 
tocol converters that connect PC Windows applications to 
NetCap. 

Additionally supported by MCI is an 800 Configuration 
Manager which is an 3270 mainframe based product having 
the following capabilities: 

1) Managing Logical Termination ("Lterm") orders by 
providing capability to add, change, or delete Dialed Num- 

3Q her Identification Service ("DNIS") and Enhanced DNIS 
values. These service features affect the termination of a Toll 
Free call by allowing customers to terminate two or more 
8xx numbers to a single service group to receive pulsed 
digits and identify the specific 8xx number dialed. The 800 

3j CM functions allow users to add, change, or delete DNIS 
digits for a termination already using DNIS. 

2) Providing Network Call Redirect ("NCR") functional- 
ity allowing customers to define, activate, and display NCR 
tables comprising instructions for calls needing termination 

40 overflow. 

3) Displaying of toll-free network trigger points and 
active/inactive status. 

4) Enabling the management of supplemental codes, e.g., 
ID Codes and Accounting Codes, that are additional num- 

^5 bers entered after a Toll Free number is dialed. 

5) Providing Call blocking service at the following levels: 
Geographic, 8xx, Enterprise, Corp Id, and ANl (8xx, SAC, 
Freephone), 

6) Providing Enhanced Voice Services ("EVS'*) including 
automated voice response, voice processing, and call routing 
functionality. The call processing behind EVS is Enhanced 
Call Routing (ECR) which is supported by 800 CM to 
control routing plans on the MRS/ECR platform. The cur- 
rent ECR environment uses 'hidden' 800 numbers to buUd 
and control the routing after it leaves the platform. 

7) Providing Intelligent Call Routing ("ICR") features 
through MCI's NetCap order entry system which allows 
customers to control the routing of their incoming Toll Free 

60 traffic on a call by call basis. Using rules defined by the 
customer, changes in Toll Free traffic routing are performed 
in real time based on changes in status at customer termi- 
nations. Particularly, NetCap flags the Corporate ID as an 
ICR account; creates and maintains trigger points; and 

65 creates and maintains destination labels. 

Thus, for a special service number (i.e., SOO/Sxx number), 
NetCap functions enable a customer to define up to 100 
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routing plans, only one of which is active at any time. 
Multiple routing plans are used by NetCap's alternate rout- 
ing feature: a customer can change routing plans on-the-fly 
with a NetCap "IMPL" order. A plan can specify routing 
rules (where to route a call) that are based on point of call 5 
origination, day of week, time of day, percent allocation of 
traffic, and other features. Features are specified with a 
NetCap "FBAT" order. Acustomer can also submit a NelCap 
"QUIK" order to temporarily change the percent allocation 
of traffic for a number. This is used, for example, in the case 
of a disaster at a certain destination. NetCap may also be 
used to configure terminations; configuration includes speci- 
fication of outpulsed digits, whether termination is domestic 
or international (determines signaling), whether termination 
is a Dedicated Access Line or a shared Feature Group 
(determines signaling), and overflow routing. ^5 

Currently, the IMPL, FEAT, and QUIK orders are pro- 
vided by the MSV 800NM platform. 

While the current 800NM and toUfree network manage- 
ment features in the current MSV platform are sufficient for 
those with existing access, a need exists to provide a newer, 
faster platform with new toll free network management 
capabilities for customers through the public Internet. 

Moreover, a need exists to integrate the existing tolLfree 
network management client-server application in a Web- 
based platform which provides expedient comprehensive ^ 
and more secure data access and reporting services to 
customers from any Web browser on any computer work- 
station anywhere in the world. 

SUMMARY OF THE INVENTION 30 

The present invention is directed to a novel toll-free 
network management tool for a Web -based (Internet and 
Intranet) client-server application that enables customers to 
define their own 800/8xx loll free number routing plans via 
the Web/lntemet. The toll-free network management tool ^5 
enables customers to change and modify their existing 
800/8xx toll free number routing plans, e.g., specifying 
routing rules for directing 800/8xx toll free calls along 
different routes and terminations based on pre-determined 
criteriaj or, temporarily change the percent allocation of 
traffic for a particular 800/8xx toll free number based on 
certain criteria. The client server application is a Web-based, 
object-oriented application that implements a Remote 
Method Invocation-like protocol providing customers with 
toll-free network management features including: stacking 45 
order capability, e.g., to temporarily change the routing of 
toll free traffic; enabling enhanced order queries; enabling 
the automatic notification of order completion or rejection; 
and providing enhanced inventory reporting. 

According to the principles of the invention there is 
provided a toll-free network management tool that enables 
customers of telecommunications network providers to 
modify the configuration of their toll-free networks via a 
Web/Internet-based graphical user interface. The tool pro- 
vides customers WcbAnternet access to toll-free call routing 
plans and associated routing plan details via a secure Web/ 
Internet-based connection, and additionally provides a cus- 
tomer with the ability to specify implementation of a specific 
call routing plan for a toll-free number at a predetermined 
time, and the ability to re-configure an existing call routing 
plan. Additionally, the tool enables a roll-back of a particular 
call-routing plan or call plan detail to a prior configuration 
at a user-specified time. 

BRIEF DESCRIPTION OF THE DRAWINGS ^5 

Further features and advantages of the invention will 
become more readily apparent from a consideration of the 
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following detailed description set forth with reference to the 
accompanying drawings, which specify and show preferred 
embodiments of the invention, wherein like elements are 
designated by identical references throughout the drawings; 
and in which: 

FIG. 1 illustrates the software architecture component 
comprising a three-tiered structure; 

FIG. 2 is a diagrammatic overview of the software archi- 
tecture of the networkMCI Interact system; 

FIG. 3 is an illustrative example of a backplane architec- 
ture schematic; 

FIG. 4 illustrates an example client GUI presented to the 
client/customer as a browser web page; 

FIG. '5 is a diagram depicting the physical networkMCI 
Interact system architecture; 

FIG. 6 is a general block diagram depicting the physical 
architecture of the TFNM system components; 

FIG. 7 is a flow diagram depicting the web-based, toll free 
network manager of the invention; 

FIG. 8 illustrates an exemplar nMCI Interact systems 
home page; 

FIGS. 9{a)-9{c) illustrate an exemplary TFNM screen 
providing functionality through option menus; 

FIG. 10 illustrates an example display when the File/ 
Select Corp ID menu option of FIG. 8 is selected; 

FIG. 11 illustrates an exemplar screen display depicting a 
hierarchical tree view of an example toll-free number rout- 
ing plan; 

FIG. 12 illustrates an example IMPL dialog screen 
enabling the user to generate a TEMP IMPL/IMPL order for 
a desired Corp Id; 

FIG. 13 iUustrates an example QUIK dialog screen 
enabling the user to generate a TEMP QUIK/QUIK order for 
a desired Corp Id; 

FIG. 14 illustrates an exemplar screen display showing 
the results of an order query; 

FIG. 15 illustrates an exemplary screen display showing 
the options for changing existing network plan routing 
orders. 

DETAILED DESCRIPTION OF THE 
INVENTION 

The present invention is one component of an integrated 
suite of customer network management and report applica- 
tions using a Web browser paradigm. Known as the net- 
workMCI Interact system ("nMCI Interact") such an inte- 
grated suite of Web-based applications provides an 
invaluable tool for enabling customers to manage their 
telecommunication assets, quickly and securely, from any- 
where in the world. 

As described in co-pending U.S. patent application Ser. 
No. 09/159,695, the nMCI Interact system architecture is 
basically organized as a set of common components com- 
prising the following: 

1) an object-oriented software architecture detailing the 
client and server based aspect of nMCI Interact; 

2) a network architecture defining the physical network 
needed to satisfy the security and data volume require- 
ments of the networkMCI System; 

3) a data architecture detailing the application, back-end 
or legacy data sources available for networkMCI Inter- 
act; and 

4) an infrastructure covering security, order entry, 
fulfllhnent, billing, self-monitoring, metrics and sup- 
port. 
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Each of these common component areas will be generally 
discussed hereinbelow. A detailed descriptions of each of 
these components can be found in a related, co-pending U.S. 
patent application Ser. No. 09/159,695, entitled H^TTE- 
GRATED CUSTOMER INTERFACE SYSTEM FOR s 
COMMUNICATIONS NETWORK MANAGEMENT, the 
disclosure of which is incorporated herein by reference 
thereto. 

FIG. 1 is a diagrammatic illustration of the software 
architecture component in which the present invention func- lo 
tions. Afirst or client tier 10 of software services are resident 
on a customer work station 10 and provides customer access 
to the enterprise system, having one or more downloadable 
application objects directed to front end business logic, one 
or more backplane service objects for managing sessions, is 
one or more presentation services objects for the presenta- 
tion of customer options and ctistomer requested data in a 
browser recognizable format and a customer supplied 
browser for presentation of customer options and data to the 
customer and for internet communications over the public 20 
Internet. Additionally applications are directed to front end 
services such as the presentation of data in the form of tables 
and charts, and data processing functions such as sorting and 
summarizing in a maimer such that multiple programs are 
combined in a unified application suite. 25 

A second or middle tier 12, is provided having secure web 
servers and back end services to provide applications that 
establish msqv sessions, govern user authentication and their 
entitlements, and communicate with adaptor programs to 
simphfy the interchange of data across the network. 30 

A third or back end tier 15 having appHcations directed to 
legacy back end services including database storage and 
retrieval systems and one or more database servers for 
accessing system resources from one or more legacy hosts. 

Generally, as explained in U.S. Pat. No. 6,115,040, 35 
entitled GRAPHICAL USER INTERFACE FOR WEB 
ENABLED APPLICATIONS, the contents and disclosure of 
which is incorporated herein by reference thereto, the cus- 
tomer workstation includes chent software capable of pro- 
viding a platform-independent, browser-based, consistent 40 
user interface implementing objects programmed to provide 
a reusable and common GUI abstraction and problem- 
domain abstractions. More specifically, the client-tier soft- 
ware is created and distributed as a set of Java classes 
including the applet classes to provide an industrial strength, 45 
object-oriented environment over the Internet. Application - 
specific classes are designed to support the functionality and 
server interfaces for each application with the functionality 
delivered through the system being of two-types: 1) cross- 
product, for example, inbox and reporting functions, and 2) 50 
product specific, for example, toll free network management 
or Call Manager functions. The system is capable of deliv- 
ering to customers the functionality appropriate to their 
product mix. 

FIG. 2 is a diagrammatic overview of the software archi- 55 
tecture of the networkMCI Interact system including: the 
Customer Browser (a.k.a. the CUenl) 20; the Demilitarized 
Zone (DMZ) 17 comprising a Web Servers cluster 24; the 
MCI Intranet Dispatcher Server 26; and the MCI Intranet 
AppUcatioQ servers 30, and the data warehouses, legacy 60 
systems, etc. 40. 

The Customer Browser 20, is browser enabled and 
includes client applications responsible for presentation and 
front -end services. Its functions include providing a user 
interface to various MCI services and supporting commu- 65 
nications with MCFs Intranet web server cluster 24. As 
illustrated in FIG. 3, and more specifically described in the 
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above-mentioned, co-pending U.S. Pat. No. 6,115,040, 
entiUed GRAPHICAL USER INTERFACE FOR WEB 
ENABLED APPLICATIONS, the chent tier software is 
responsible for presentation services to the customer and 
generally includes a web browser 14 and additional object- 
oriented programs residing in the client workstation plat- 
form 20. The client software is generally organized into a 
component architecture with each component generally 
comprising a specific application, providing an area of 
functionality. The applications generally are integrated using 
a "backplane" services layer 12 which provides a set of 
services to the application objects which provide the front 
end business logic and manages their launch. The network- 
MCI Interact common set of objects provide a set of services 
to each of the applications such as: 1) session management; 
2) application launch; 3) inter-application communications; 
4) window navigation among appHcations; 5) log manage- 
ment; and 6) version management. 

The primary common object services include: graphical 
user interface (GUI); communications; printing; user 
identity, authentication, and entitlements; data import and 
export; logging and statistics; error handhng; and messaging 
services. 

FIG. 3 is a diagrammatic example of a backplane archi- 
tecture scheme illustrating the relationship among the com- 
mon objects. In this example, the backplane services layer 
12 is programmed as a Java applet which can be loaded and 
launched by the web browser 14. With reference to FIG. 3, 
a typical user session starts with a web browser 14 creating 
a backplane 12, after a successful logon. The backplane 12, 
inter alia, presents a user with an interface for networkMCI 
Interact application management. A typical user display 
provided by the backplane 12 may show a number of 
applications the user is entitled to run, each application 
represented by buttons depicted in FIG. 3 as buttons 5Ha,b,c 
selectable by the user. As IQustrated in FIG. 3, upon selec- 
tion of an application, the backplane 12 launches that 
specific application, for example. Service Inquiry 54a or 
Alarm Monitor 54fc, by creating the application object. In 
processing its functions, each application in turn, may utilize 
common object services provided by the backplane 12. FIG. 
3 shows graphical user interface objects 56a,b created and 
used by a respective appfication 54a, for its own presen- 
tation purposes. 

FIG. 4 illustrates an example client GUI presented to the 
client/customer as a browser web page 80 providing, for 
example, a suite 70 of network management reporting 
applications including: MCI Traffic Monitor 72; an alarm 
monitor 73; a Network Manager 74 and Intelligent Routing 
75. Access to network functionality is also provided through 
Report Requester 76, which provides a variety of detailed 
reports for the client/customer and a Message Center 77 for 
providing enhancements and functionality to traditional 
e-mail communications. 

As shown in FIGS. 3 and 4, the browser resident GUI of 
the present invention implements a single object, COBack- 
Plane which keeps track of all the client applications, and 
which has capabilities to start, stop, and provide references 
to any one of the client applications. 

The backplane 12 and the cHent applications use a 
browser 14 such as the Microsoft Explorer versions 4.0.1 or 
higher for an access and distribution mechanism. Although 
the backplane is initiated with a browser 14, the cHent 
applications are generally isolated from the browser in that 
they typically present their user interfaces in a separate 
frame, rather than sitting inside a Web page. 

The backplane architecture is implemented with several 
primary classes. These classes include CO Backplane, 
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COApp, COAppImpl, COParm. and COAppFrame classes. 
CO Backplane 12 is an application backplane which 
launches the applications 54a, 546, typically implemented as 
COApp. COBackPlane 12 is generally implemented as a 
Java applet and is launched by the Web browser 14. This 5 
backplane applet is responsible for launching and closing the 
COApps. 

When the backplane is implemented as an applet, it 
overrides standard Applet methods imt( ), start( ), stop( ) and 
run( ). In the init( ) method, the backplane applet obtains a lO 
COUser user context object. The COUser object holds 
information such as user profile, applications and their 
entitlements. The user's configuration and applicatioQ 
entitlements provided in the COUser context are used to 
construct the application toolbar and Inbox applications. 15 
When an application toolbar icon is clicked, a particular 
COApp is launched by launchAppQ method. The launched 
application then may use the backplane for inter-application 
communications, including retrieving Inbox data. 

The COBackPlane 12 includes methods for providing a 20 
reference to a particular COApp, for interoperation. For 
example, the COBackPlane class provides a getAppQ 
method which returns references to application objects by 
name. Once retrieved in this manner, the application object's 
public interface may be used directly. 25 

The use of a set of common objects for implementing the 
various functions provided by the system of the present 
invention, and particularly the use of browser based objects 
to launch applications and pass data therebetween is more 
fully described in the above -referenced, co-pending patent 30 
application GRAPHICAL USER INTERFACE FOR WEB 
ENABLED APPLICATIONS. 

As shown in FIG. 2, the aforesaid objects will commu- 
nicate the data by establishing a secure TCP messaging 
session with one of the DMZ networkMCI Interact Web 35 
servers 24 via an Internet secure communications path 22 
established, preferably, with a secure sockets SSL version of 
HTTPS. The DMZ networkMCI Interact Web servers 24 
function to decrypt the client message, preferably via the 
SSL implementation, and unwrap the session key and verify 40 
the users session. After establishing that the request has 
come from a valid user and mapping the request to its 
associated session, the DMZ Web servers 24 will re-encrypt 
the request using symmetric encryption and forward it over 
a second socket connection 23 to the dispatch server 26 45 
inside the enterprise Intranet. 

As described in greater detail in commonly owned, 
co-pending U.S. patent appUcation Ser. No. 09/159,514, 
now allowed, entitled SECURE CUSTOMER INTERFACE 
FOR WEB-BASED DATA MANAGEMENT, the contents 50 
and disclosure of which is incorporated by reference as if 
fully set forth herein, a networkMCI Interact session is 
designated by a logon, successful authentication, followed 
by use of server resources, and logoff. However, the world- 
wide web communications protocol uses HTTP, a stateless 55 
protocol, each HTTP request and reply is a separate TCP/IP 
connection, completely independent of all previous or future 
connections between the same server and client. The nMCI 
Interact system is implemented with a secure version of 
HTTP such as S-HTTP or HTTPS, and preferably utilizes 60 
the SSL implementation of HTTPS, The preferred embodi- 
ment uses SSL which provides a cipher spec message which 
provides server authentication during a session. The pre- 
ferred embodiment further associates a given HTTPS 
request with a logical session which is initiated and tracked 65 
by a "cookie jar server*' 28 to generate a "cookie" which is 
a unique server-generated key that is sent to the client along 
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with each reply to a HTTPS request. The cUent holds the 
cookie and returns it to the server as part of each subsequent 
HTTPS request. As desired, either the Web servers 24, the 
cookie jar server 28 or the Dispatch Server 26, may maintain 
the "cookie jar" to map these keys to the associated session. 
A separate cookie jarserver 28, as illustrated in FIG. 2 has 
been found desirable to minimize the load on the dispatch 
server 26. This form of session management also functions 
as an authentication of each HTTPS request, adding an 
additional level of security to the overall process. 

As illustrated in FIG. 2, after one of the DMZ Web servers 
24 decrypts and verifies the user session, it forwards the 
message through a firewall 25b over a TCP/IP connection 23 
to the dispatch server 26 on a new TCP socket while the 
original socket 22 from the browser is blocking, waiting for 
a response. The dispatch server 26 will unwrap an outer 
protocol layer of the message from the DMZ services cluster 
24, and wiU reencrypt the message with symmetric encryp- 
tion and forward the message to an appropriate application 
proxy via a third TCP/IP socket 27. While waiting for the 
proxy response all three of the sockets 22, 23, 27 will be 
blocking on a receive. Specifically, once the message is 
decrypted, the wrappers are examined to reveal the user and 
the target middle-tier (Intranet appUcation) service for the 
request. A first-level validation is performed, making sure 
that the user is entitled to communicate with the desired 
service. The user's entitlements in this regard are fetched by 
the dispatch server 26 from StarOE server 49 at logon time 
and cached. 

If the requestor is authorized to communicate with the 
target service, the message is forwarded to the desired 
service's proxy. Each application proxy is an application 
specific daemon which resides on a specific Intranet server, 
shown in FIG, 2 as a suite of mid-range servers 30. Each 
Intranet application server of suite 30 is generally respon- 
sible for providing a specific back-end service requested by 
the client, and, is additionally capable of requesting services 
from other Intranet application servers by communicating to 
the specific proxy associated with that other application 
server. Thus, an application server not only can offer its 
browser a client to server interface through the proxy, but 
also may ofifer all its services from its proxy to other 
appUcation servers. In effect, the appUcation servers request- 
ing service are acting as cUents to the application servers 
providing the service. Such mechanism increases the secu- 
rity of the overall system as weU as reducing the number of 
interfaces. 

The network architecture of FIG. 2 may also include a 
variety of application specific proxies having associated 
Intranet appUcation servers including: a StarOE proxy for 
the StarOE application server 39 for handling authentication 
order entry/bilUng; an Inbox proxy for the Inbox appUcation 
server 31, which functions as a container for completed 
reports, call detail data and marketing news messages, a 
Report Manager Proxy capable of commimicating with a 
system-specific Report Manager server 32 for generating, 
managing and scheduling the transmission of customized 
reports including, for example: call usage analysis informa- 
Uon provided from the StarODS server 33; network trafl&c 
analysis/monitor information provided from the Traffic view 
server 34; virtual data network alarms and performance 
reports provided by Broadband server 35; trouble tickets for 
switching, transmission and traffic faults provided by Ser- 
vice Inquiry server 36; and toll free routing information 
provided by ToU Free Network Manager server 37. 

As partially shown in FIG. 2, it is understood that each 
Intranet server of suite 30 communicates with one or several 



rsion: 1.4.1 



us 6,574,661 Bl 

9 10 

consolidated network databases which include each custom- customer attacks; and, 3) the MCI Intranet Midrange Servers 

er's network management information and data. In the 30 and Legacy Mainframe Systems 40 which comprise the 

present invention the Services Inquiry server 36 includes back end business logic applications, 

communication with MCFs Customer Service Management As illustrated in FIG. 5, the present invention includes a 

legacy platform 40(a). Such network management and cus- s double or complex firewall system that creates a "demilita- 

tomer network data is additionally accessible by authorized rized zone" (DMZ) between two firewalls 25a, 25b. In the 

MCI management personnel. As shown in FIG. 2, other preferred embodiment, one of the firewalls 29 includes port 

legacy platforms 40(b), 40(c) and 40(d) may also commu- specific filtering routers, which may only connect with a 

nicate individually with the Intranet servers for servicing designated port on a dispatch server within the DMZ. The 

specific transactions initiated at the client browser. The lo dispatch server connects with an authentication server, and 

illustrated legacy platforms 4Q(a)-(d) are illustrative only through a proxy firewall to the application servers. This 

and it is understood other legacy platforms may be inter- ensures that even if a remote user ID and password are 

preted into the network architecture Ulustrated in FIG. 2 hijacked, the only access granted is to one of the web servers 

through an intermediate midrange server 30. 24 or to intermediate data and privileges authorized for that 

Each of the individual proxies may be maintained on the 15 user. Further, the hijacker may not directly connect to any 

dispatch server 26, the related application server, or a enterprise server in the enterprise intranet, thus ensuring 

separate proxy server situated between the dispatch server internal company system security and integrity. Even with a 

26 and the midrange server 30. The relevant proxy waits for stolen password, the hijacker may not connect to other ports, 

requests from an application client running on the custom- root directories or applications within the enterprise system, 

er's workstation 10 and then services the request, either by 20 The DMZ acts as a double firewall for the enterprise 

handling them internally or forwarding them to its associ- intranet because the web servers located in the DMZ never 

ated Intranet application server 30. The proxies additionally store or compute actual customer sensitive data. The web 

receive appropriate responses back from an Intranet appli- servers only put the data into a form suitable for display by 

cation server 30. Any data returned from the Intranet appH- the customer's web browser. Since the DMZ web servers do 

cation server 30 is translated back to client format, and 25 not store customer data, there is a much smaller chance of 

returned over the internet to the client workstation 10 via the any customer information being jeopardized in case of a 

Dispatch Server 26 and at one of the web servers in the DMZ security breach. 

Services cluster 24 and a secure sockets connection. When As previously described, the customer access mechanism 

the resultant response header and trailing application spe- is a client workstation 20 employing a Web browser 14 for 

cific data are sent back to the client browser from the proxy, 30 providing the access to the networkMCI Interact system via 

the messages will cascade all the way back to the browser 14 the public Internet 15, When a subscriber connects to the 

in real time, limited only by the transmission latency speed networkMCI Interact Web site by entering the appropriate 

of the network. URL, a secure TCP/IP communications link 22 is estab- 

The networkMCI Interact middle tier software includes a lished to one of several Web servers 24 located inside a first 

communications component offering three (3) types of data 35 firewall 29a in the DMZ 17. Preferably at least two web 

transport mechanisms: 1) Synchronous; 2) Asynchronous; servers are provided for redundancy and failover capability, 

and 3) Bulk transfer. Synchronous transaction is used for In the preferred embodiment of the invention, the system 

situations in which data will be returned by the application employs SSL encryption so that communications in both 

server 40 quickly. Thus, a single TCP connection will be directions between the subscriber and the networkMCI 

made and kept open until the full response has been ^o Interact system are secure. 

retrieved. In the preferred embodiment, all DMZ Secure Web serv- 
Asynchronous transaction is supported generally for situ- ers 24 are preferably DEC 4100 systems having Unix or 
ations in which there may be a long delay in application NT-based operating systems for running services such as 
server 40 response. Specifically, a proxy will accept a HTTPS, FTP, and Telnet over TCPAP. The web servers may 
request from a customer or client 10 via an SSL connection 45 be interconnected by a fast Ethernet LAN running at 100 
and then respond to the client 10 with a unique identifier and Mbit/sec or greater, preferably with the deployment of 
close the socket connection. The client 10 may then poll switches within the Ethernet LANs for improved bandwidth 
repeatedly on a periodic basis until the response is ready. utilization. One such switching unit included as part of the 
Each poll will occur on a new socket connection to the network architecture is a HydraWEB™ unit 45, manufac- 
proxy, and the proxy will either respond with the resultant 50 tured by Hydra WEB Technologies, Inc., which provides the 
data or, respond that the request is stiU in progress. This will DMZ with a virtual IP address so that subscriber HTTPS 
reduce the number of resource consuming TCP connections requests received over the Internet will always be received, 
open at any time and permit a user to close their browser or The Hydraweb unit 45 implements a load balancing algo- 
disconnect a modem and return later to check for results. rithm enabling intelligent packet routing and providing 
Bulk transfer is generally intended for large data transfers 55 optimal reliability and performance by guaranteeing acces- 
and are unlimited in size. Bulk transfer permits cancellation sibility to the "most available" server. It particularly moni- 
during a transfer and allows the programmer to code tors all aspects of web server health from CPU usage, to 
resumption of a transfer at a later point in time. memory utilization, to available swap space so that Internet/ 
FIG. 5 is a diagram depicting the physical networkMCI Intranet networks can increase their hit rate and reduce Web 
Interact system architecture 10. As shown in FIG. 5, the 60 server management costs. In this manner, resource utiliza- 
system is divided into three major architectural divisions tion is maximized and bandwidth (throughput) is improved, 
including; 1) the customer workstation 20 which include It should be understood that a redundant Hydraweb unit may 
those mechanisms enabling customer connection to the be implemented in a Hot/Standby configuration with heart- 
Secure web servers 24; 2) a secure network area 17, known beat messaging between the two units (not shown), 
as the DeMilitarized Zone "DMZ" set aside on MCI pre- 65 Moreover, the networkMCI Interact system architecture 
mises double firewalled between the both the public Internet affords web server scaling, both in vertical and horizontal 
25 and the MCI Intranet to prevent potentially hostile directions. Additionally, the architecture is such that new 
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secure web servers 24 may be easily added as customer e.g., ANT's, calling cards, etc.. An MCI Internet StarOE 

requirements and usage increases. The use of the server will manage the data base for the common configu- 

HydraWEB™ enables better load distribution when needed ration of data. 

to match performance requirements. Report management related data is also generated which 

As shown in FIG. 5, the most available Web server 24 5 includes 1) report profiles defining the types of reports that 

receives subscriber HTTPS requests, for example, from the are available, fields for the reports, default sort options and 

HydraWEB™ 45 over a connection 44a and generates the customizations allowed; and 2) report requests defining 

appropriate encrypted messages for routing the request to customer specific report requests including report type, 

the appropriate MCI Intranet midrange web server over report name, scheduling criteria, and subtotal fields. This 

connection 44b , router 55 and connection 23. Via the lo type of data will be resident in an Inbox server database and 

Hydraweb unit 45, a TCP/IP connection 38 links the Secure managed by the Inbox server. 

Web server 24 with the MCI Intranet Dispatcher server 26. The Infrastructure component of the nMCI Reporting 

Further as shown in the DMZ 17 is a second RTM server system includes means for providing secure communica- 

52 having its own connection to the pubfic Internet via a tions regardless of the data content being communicated- As 

TCP/IP connection 48. As described in co-pending U.S. 15 described in detail in above-referenced, co-pending U.S. 

patent application Ser. No. 09/159,516, entitled INTE- patent application Ser. No. 09A59,514, now allowed, the 

GRATED PROXY INTERFACE FOR WEB BASED nMCI Interact system security infrastructure includes: 1) 

TELECOMMUNICATIONS MANAGEMENT TOOLS, authentication, including the use of passwords and digital 

incorporated by reference as if fully set forth herein, this certificates; 2) public key encryption, such as employed by 

RTM server provides real-time session management for 20 a secure sockets layer (SSL) encryption protocol; 3) 

subscribers of the networkMCI Interact Real Time Moni- firewalb, such as described above with reference to the 

toring system. An additional TCP/IP connection 48 links the network architecture component; and 4) non-repudiation 

RTM Web server 52 with the MCI Intranet Dispatcher server techniques to guarantee that a message originating from a 

26. source in the actual identified sender. One technique 

With more particularity, as further shown in FIG. 5, the 25 employed to combat repudiation includes use of an audit 

networkMCI Interact physical architecture includes three trail with electronically signed one-way message digests 

routers: a first router 49 for routing encrypted messages from included with each transaction. 

the Public Internet 15 to the HydraWeb 45 over a socket Another component of the nMCI Interact infrastructure 
connection 44; a second router 55 for routing encrypted includes order entry, which is supported by the Order Entry 
subscriber messages from a Secure Web server 24 to the 30 ("StarOE") server. The general categories of features to be 
Dispatcher server 26 located inside the second firewall 2Sb; ordered include: 1) Priced Reporting; 2) Real-time report- 
and, a third router 65 for routing encrypted subscriber ing; 3) Priced Call Detail; 4) Real Time Call Detail; 5) 
messages from the RTM Web server 52 to the Dispatcher Broadband SNMP Alarming; 6) Broadband Reports; 7) 
server 26 inside the second firewall. Although not shown. Inbound RTM; 8) Outbound RTM; 9) Toll Free Network 
each of the routers 55, 65 may additionally route signals 35 Manager; and 10) Call Manager. The order entry function- 
through a series of other routers before eventually being ality is extended to additionally support 11) Event Monitor; 
routed to the nMCI Interact Dispatcher server 26. In 12) Service Inquiry; 13) Outbound Network Manager; 14) 
operation, each of the Secure servers 24 function to decrypt Portfolio; and, 15) Client View. 

the client message, preferably via the SSL implementation. The Self-monitoring infrastructure component for nMCI 

and unwrap the session key and verify the users session from 40 Interact is the employment of mid-range servers that support 

the CO User object authenticated at Logon. SNMP alerts at the hardware level. In addition, all software 

After establishing that the request has come from a valid processes must generate alerts based on process health, 

user and mapping the request to its associated session, the connectivity, and availability of resources (e.g., disk usage, 

Secure Web servers 24 will re-encrypt the request using CPU utilization, database availability), 

symmetric RSA encryption and forward it over a second 45 The Metrics infrastructure component for nMCI Interact 

secure socket connection 23 to the dispatch server 26 inside is the employment of means to monitor throughput and 

the enterprise Intranet. volumes at the Web servers, dispatcher server, application 

As described herein, and in greater detail in co-pending proxies and mid-range servers. Metrics monitoring helps in 

U.S. patent application Ser. No. (PCT/US98/20173), the the determination of hardware and network growth, 

data architecture component of networkMCI Interact report- 50 To provide the areas of functionality described above, the 

ing system is focused on the presentation of real time client tier 10 is organized into a component architecture, 

(un-priced) call detail data, such as provided by MCI's with each component providing one of the areas of func- 

TrafficView Server 34, and priced call detail data and tionality. As explained in further detail in co -pending U.S. 

reports, such as provided by MCTs StarODS Server 33 in a Pat. No. 6,115,040, the client-tier software is organized into 

variety of user selected formats. 55 a "component" architecture supporting such applications as 

All reporting is provided through a Report Requestor GUI inbox fetch and inbox management, report viewer and report 
application interface which support spreadsheet, a variety of requester, TFNM, Event Monitor, Broadband, Real-Time 
graph and chart type, or both simultaneously. For example. Monitor, and system administration applications. Further 
the spreadsheet presentation allows for sorting by any arbi- functionality integrated into the software architecture 
trary set of columns. The report viewer may also be launched 60 includes applications such as Outbound Network Manager, 
from the inbox when a report is selected. A common Call Manager, Service Inquiry and Client View, 
database may be maintained to hold the common configu- The present invention focuses on the client and middle- 
ration data which can be used by the GUI applications and tier service that enables customers to request, specify, and 
by the mid -range servers. Such common data will include receive and view data pertaining to their toll free network 
but not be limited to: customer security profiles, billing 65 management assets, e.g., toll free number routing plans, and 
hierarchies for each customer, general reference data (slates, to generate orders for changing aspects of the routing plans 
NPA's, Country codes), and customer specific pick lists: via a World Wide Web interface. 
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As shown in FIG. 6, the toll free network management 
tool 200 of the invention, referred to herein as "TFNM," 
implements a TFNM domain server 250 which is one 
component part of a back-end MCI intranet infrastructure 
comprising above-described MCFs NetCap order entry sys- 5 
tern 240, Service Control Manager 241 ("SCM") and Data 
Access Points 242 ("DAF*). As will be described in greater 
detail, the TFNM tool 200 of the invention enables custom- 
ers to change their toll-free network management plans, both 
in real-time and on a scheduled basis, via nMCI Interact's lO 
web-based front-end and middle-tier infrastructure. 
Particularly, customer directives are entered by the user 100 
via a TFNM graphic user interface. These directives are 
preferably communicated as Java applets over secure TCP/ 
IP socket connections for input over the firewall 25(b) to at is 
least one secure server, e.g., a DMZ Web server that pro- 
vides for authentication, validation, and session manage- 
ment in the manner as described in co-pending U.S. patent 
application Ser. No. 09/159,514, now allowed, the contents 
and disclosure of which is incorporated by reference as if 20 
fully set forth herein. As wiU be described, the TFNM server 
250 interfaces with the "NetCap" 240 mainframe system 
that provides user interface to the network control system, 
i.e., DAP switches 242 (FIG. 6). The TFNM domain server 
250 includes Java object classes whose methods are invoked 25 
by Java applets running on the customer browser. The 
browser Java applets specifically execute the customer 
directives by invoking certain methods on the TFNM 
Domain server 250. These Java objects additionally provide 
the interface functions to the NetCap 240, In the preferred 30 
embodiment, the Java objects at the TFNM domain server 
function as a proxy, and are invoked remotely implementing 
a Java remote method invocation "RMF'-like methodology. 

Particularly, as mentioned herein with respect to FIG, 2, 
within the networkMCI Interact framework for producing 35 
Java applications over the Internet, there is provided com- 
mon objects and an infrastructure allowing secure commu- 
nications between a client (which resides on a browser) and 
a server (which resides safely within MCTs firewalls). As 
described, the security strategy includes: encrypting com- 40 
munication from the client to the web -server via SSL 
(HTTPS) and implementing HTTPS as the preferred method 
for allowing communication into the web server from the 
Internet; providing an additional firewall between the web- 
server and the dispatcher to allow only specific trafi&c from 45 
the web server to the dispatcher to occur; encrypting traf&c 
between the web server and the dispatcher via DSA encryp- 
tion; and enabling the dispatcher to validate all packets 
destined to internal MCI servers to ensure that they are from 
an authenticated client, and that a particular client has so 
permission to communicate with a specific back-end server. 
To make this seamless for the client, a set of Common 
Objects performs this messaging, such as described in U.S. 
Pat. No. 6,115,040. In the preferred embodiment, the inven- 
tion implements a modified RMI which is referred to as 55 
"CORMI" (Common Objects RMI) which provides an RMI- 
like interface between the client and the server using the 
networkMCI Interact protocol. The CORMI procedures 
implemented have additional controls built in to provide the 
necessary session security and maintenance for communi- 60 
cation over the firewalls. 

More specifically, CORMI is MCI Interacts protocol for 
providing secure, client-to-server commimication with Java 
RMI -like semantics and comprises a library of Java classes 
used by both the client applet and server application. In view 65 
of FIG. 6, the communication path from the client and the 
server is as follows: 
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The TFNM server application 250 registers remote 
objects with CORMFs CORemoteSessionServer (analogous 
to Java RMFs Registry service) and then blocks waiting for 
connections. The TFNM client applet initiates communica- 
tion by performing a logon through a COClientSession 
object. The COQientSession creates a COSynchTransaction 
(an atomic unit of work based over an HTTPS socket) which 
connects to the MQ Interact system dispatcher server 235 
(which is behind the outer firewall 25(t)). The dispatcher 
server 235 process validates the client's authorization to 
logon (a process that involves contacting the StarOE service 
and generating a session key with a 'cookiejar' process). 
After validating the client, the dispatcher uses a round-robin 
protocol to select a TFNM server and then opens an HTTPS 
connection to an instance of the TFNM server application. 
On this server, the CORemoteSessionServer creates a new 
session for this client and records the session key. 

A reply to a logon is sent back through the dispatcher to 
the client 100. The client then can do a lookup which results 
in a serialized remote interface of the remote object regis- 
tered carUer being passed back to the client. The client can 
then use this remote interface as it would with Java RMI- 
doing remote method invocations. The remote method invo- 
cations are handled by CORMI as COSynchTransactions 
through the dispatcher to the same TFNM server instance 
that the logon and interface lookup took place at. 

It should be understood that there is no permanent con- 
nection between the TFNM client and server; CORMI, 
through a COSynchTransaction, creates a new HTTPS con- 
nection to the dispatcher (and the dispatcher creates a 
connection to the TFNM server) for each unit of commu- 
nication. 

As shown in the process flow diagram of FIG. 7, a 
customer first types in the URL into the Web Browser where 
a connection is made to the networkMCI Interact web page, 
as indicated at step 302. Having accessed the web page, the 
user logs in, as indicated at step 305, and a user Common 
Object is created. At this point, a message is sent via an 
established HTTPS connection via a Dispatcher Server 235 
(FIG. 6) to the StarOE Server 260 to validate the customer 
as indicated at step 307. Once the customer is validated, at 
step 308a^ fc, the backplane objects request a list of all the 
authorized applications from the StarOE server, as indicated 
at step 310. At steps 312 and 314 respectively, a network- 
MCI Interact applet is downloaded to the customers Web 
Browser via the established HTTPS connection, and the 
browser presents the customer with the networkMCI Interact 
systems home page, such as the exemplary home page 292 
shown in FIG. 8. It should be understood that in the 
preferred embodiment, the icons for applications the user 
has security access to are shown bolded. Referring back to 
FIG. 7, at step 314, the customer selects the TFNM appli- 
cation from the home page by clicking on a Network 
Manager icon 293 (FIG. 8) after StarOE validates the user's 
id and password in the manner as described in commonly 
owned, co-pending U.S. patent application Ser. No, 09/159, 
408, entitled AUTHENTICATION AND ENTITLEMENTS 
FOR USERS OF WEB BASED DATA MANAGEMENT 
PROGRAMS, the contents and disclosure of which is incor- 
porated by reference as if fully set forth herein. The back- 
plane object allows the user access to the TFNM front end 
if the user is so authorized. As shown at step 316, a chent 
TFNM application is downloaded to the customer who is 
presented with the TFNM screen, as indicated at step 318. 

An exemplary TFNM web-page display 294 is shown in 
FIG, 9(a) which presents a variety of TFNM file menu 
options including: 1) an option 295 enabling a user to select 
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a Corp ID, i.e., a corp, set, number, and plan to establish a and/or number selected by the user up to that point. It should 

working environment; 2) an option 296 enabling a user to be understood that the TFNM server is enabled to commu- 

cut-through to a 3270 mainframe NetCap application; 3) an nicate with NetCap server for this data if not provided in the 

option 297 enabling a user to Implement Plan, i.e., put apian TFNM database, or, if the infonnation in TFNM is not 

in use by creating an IMPL order; and, 4) an option 298 5 current. For instance, for some messages, a data sync may 

enabling a user to modify the termination of a routing plan always be invoked. Thus, TFNM may contact NetCap and 

by creating a QUIK order. As further shown in FIG. 9(i)), the pass date and time stamps indicating the last update for the 

open menu includes a Plan option 285 which allows the user record. If NetCap determines that they have later data 

to select from a list of plans in the current working envi- version, it will pass down the updated version, otherwise, it 

ronment and enables opening of the plan in a graphical mode lO will pass an empty message back to TFNM. Alternately, an 

on a VORT ("View Only Routing Tree"), as will be internal table 245, as shown in FIG. 6, may be accessed 

explained; and a Tree View option 286 which displays the indicating the intervals for data record updates and which 

last plan accessed on the VORT screen. As further shown in will indicate the last time a data sync was performed for a 

FIG. 9(c), the report menu includes an option 287 for particular record. By checking this table, a determination 

allowing the user to set up and execute an order filter query is may be made as to whether contact must be made to NetCap 

which results in the display of an order list, as will be for a data update. 

hereinafter described in greater detail. Thus, referring back In the preferred embodiment, as shown in FIG, 6, the 

to FIG. 7, at step 321, the customer is enabled to select a TFNM server 250 communicates a plan/data sync message 

view of his/her routing plans in accordance with that user's 243 via Registry messaging to NetCap. Appendix A illus- 

privileges. To determine privileges, as indicated at step 326, 20 trates the Registry message call "NPSNC which is the 

TFNM user security profile information is requested from request to sync a plan and transmitted from the TFNM server 

StarOE that comprises a list of Corp Ids and Accessid to NetCap. A variety of Registry response messages for this 

combinations, referred to herein as "RACF ID" combina- request is provided in Appendix B. 

tions that the customer is allowed to access within TFNM. As shown in FIG. 10, the File/Select Corp ID menu option 

Particularly, user security profile elements obtained from 25 causes a screen to be displayed that enables the user to select 

StarOE include: Corp Id, i.e., the Corporation Id the cus- elements (Corp ID, Set ID, Routing Number) that invoke 

tomer user has access to within StarOE; and Defaultind , i.e., objects for establishing a working environment, or, to select 

a default Corpid indicator having, for example, *Y' or *N' a plan for view. The data elements displayed on this screen 

values. differ according to the type of plan chosen. In the preferred 

Once the customer has logged into TRsTM and has 30 embodiment, the TFNM Network Manager 200 enables the 

received the StarOE security message, a communication is customer to create or modify orders for four types of TFNM 

made from the TFNM server 250 to NetCap 240, as indi- routing plans: a Number Level Plan ("NLP"), Super Routing 

cated at step 328, requesting a user security profile. Plans ("SRP"), Enhanced Voice Service Routing plans 

Particularly, the messaging system implemented for all ("EVS"), and universal routing plans ("URP"). As shown in 

communications between the TFNM server and NetCap is 35 FIG. 10, Number Level, EVS, or Super Routing plan radio 

referred to herein as "Registry", such as shown and buttons 265 may be selected to access corresponding visible 

described in commonly-owned, co-pending U.S. Pat. No. screenelements. When an NLP plan is selected, for instance, 

5,790,809, the contents and disclosure of which are incor- the following elements are displayed: a Corp ID element 266 

porated by reference as if fully set forth herein. Security which is a single selection list box that becomes populated 

from NetCap is by Racf Id and Corp Id. For each Corp Id a 40 with corp id's available to the user in accordance with that 

user has access to, that user must have a Racf Id. If a user user^s entitlements; a Set ID element 267 which is a single 

has Enterprise level security, then the list of Corps under that selection list box populated with Set ID's that the user has 

Enterprise within NetCap have the same security as the security access to for a chosen Corp ID; a Number list box 

Enterprise. Particularly, in response to a user login, in the element 268 which is a single selection list box populated 

preferred embodiment, a TFNM server application is 45 with number information for the indicated corp./set; and, a 

executed. From this application, the TFNM server instanti- Plan list box 269 which is a single selection list box 

ates a Profile Manager Java object which is registered with populated with plan information such as: a plan description, 

CORMI and called upon to invoke further objects relating to plan in use, or when the plan was last modified, for the 

the following: user profile, e.g., preferences, user security selected number. It should be understood that corporate 

profiles, i.e., for tracking customer entitlements/privileges 50 security is obtained firom NetCap whenever a new Corp ID 

including rights for creating or modifying specific TFNM is selected, in the manner described, 

routing plans or generating QUIK or IMPL orders; and. In the preferred embodiment, using additional buttons 

session management, i.e., objects which encapsulate the 262, 263 and 264 from the screen shown in FIG. 10, the user 

state and behavior associated with a specific user login, e.g., respectively, is enabled to open or close the "plan" portion 

time logged in. 55 of the screen; save the selected corp/set/number/plan id as 

In the preferred embodiment, once profile manager is the user's current working environment; and/or display a 

instantiated at step 328, the TFNM server additionally tree view of the highlighted plan. 

instantiates objects related to view screens and options When the user chooses to view a selected routing plan, 

according to the user's entitlements/privileges. Specifically, and after verifying security with both StarOE and NetCap, 

a Corporation Manager ("CoipMng?*) object is invoked to 60 the TFNM server may execute the synch process with 

enable the user to select the corporation having the desired NetCap 240, as indicated at step 330, FIG. 7 and described 

routing plan to be looked at. Then, the following objects are above. During this process, TFNM updates any records in 

sequentially invoked: a Set Manager object for the corpo- the TFNM server copy of the customer's chosen routing plan 

ration selected; a Number Manager object that knows the with changes that were made in NetCap since the user last 

TFNM numbers (e.g., l-800/8xx) belonging to the Set 65 accessed the system. The TFNM server database is updated 

and/or Corp; and, a Plan Manager object, which knows the with the latest routing plan information for that customer, 

routing plans that belong to the selected corporation, set, and the updated routing plan information is sent to the user. 
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as indicated at step 333. The customer is now presented with 
the requested routing plan view at step 335 via the TFNM 
client application, as shown in FIG. 6. 

A user may view a routing plan in several formats, e.g., a 
hierarchical tree graphic or a spreadsheet. In the preferred s 
embodiment, as shown in the exemplar screen display of 
FIG. 11, the Routing Plan is displayed as a tree structure 
comprising of a series of linked node types in a specific 
hierarchy. As shown in FIG. 11, the screen is divided into 
two main sections: a first section 272 comprising the graphi- lO 
cal representation of the routing tree having nodes tree 
branches that can be expanded and collapsed; and, a second 
section 273 for displaying the details of the currently high- 
lighted tree node. The node types that are available include: 
1) a Plan node 276a which is shown highlighted in FIG. 11 15 
and details the features for the plan; 2) an Origination node 
("ORIG") 2766 which details the geographical elements 
used in determining where to route the call. Multiple Origi- 
nation nodes may exist under a plan node; 3) a Day of Week 
node ("DOW") 276c which details how to route calls based 20 
on days of the week. Multiple Day of Week nodes may exist 
under an Origination and all seven days of the week must be 
accounted for under each origination; 4) a Time of Day node 
("TOD") 21 6d which details specific time ranges for routing 
calls. Multiple Time of Day nodes may exist under a Day of 25 
Week and all 24 hours of the day must be accounted for 
under each Day of Week; and, 5) a Percent Logical Termi- 
nation node ("%LTERM") 276e which details where the 
calls terminate and at what percentage of the time. As shown 
in FIG. 11, multiple ^LTCRM nodes may exist under a 30 
Time of Day. The percentages in "sibling" nodes must add 
up to 100 percent. A user can select details of any node by 
clicking or scrolling. Trigger Points (not shown) may also be 
displayed as children of the node they ride on. For example, 
a Trigger Point that rides on an Origination node would be 35 
displayed under the Origination on the same level as a 
Day-of-Week node. At each node, decisions related to the 
call routing are executed. 

As shown in FIG. 11, for a plan node, the corresponding 
plan detail screen 273 is populated with the existing plan 40 
description; the Orig id of the default orig on the plan; and 
Origination Features having values derived based on the 
features in use on the plan. Likewise, for an origination node 
21 6b J the corresponding plan detail screen displays: the ID 
of the highlighted origination node and the corresponding 45 
description including listboxes displaying the geographic 
elements (countries, states, area codes and exchanges) asso- 
ciated with the highlighted Origination node. For the DOW 
node 276c, the corresponding plan detail screen displays the 
Day Id of the DOW node and the list of days associated with 50 
the DOW node. For the TOD node 276cf, the corresponding 
plan detail screen displays the list of time ranges associated 
with the TOD node. For the Termination node 276e, the 
corresponding plan detail screen displays: the ID of the 
termination associated with the highlighted node; a descrip- 55 
tion of the termination associated with the highlighted node; 
an indication of whether a cross corp term is associated with 
the highlighted node, and, if the Cross Corp Term indicator 
is *'Yes," a field displaying the cross corp Id associated with 
the termination in the Termination ID field; and an indication 60 
of the percentage of calls allocated to this termination node. 
Further details may be displayed including a Details tab (not 
shown) for displaying: the customer service id associated 
with the termination; the activation date of the termination; 
the activation date received associated with the termination; 65 
the service status associated with the termination; the Switch 
Trunk ID associated with the termination; and, an indication 



of whether the termination is EVS; whether the Termination 
has a real-time ANT Delivery and, the activation date for the 
Real Time ANl. Additionally, an AN! tab (not shown) may 
be displayed for presenting the user with information as to 
whether the termination has an Automatic Number Identifier 
("ANI")> the country code associated with the termination 
and the Termination ANI. An "Overflow"' tab of the termi- 
nation details screen displays for the user: a network call 
redirect indicator indicating whether the termination has an 
NCR; a direct termination overflow indicator indicating 
whether the termination has a DTO. Likewise, a "DNIS" tab 
(not shown) may be displayed for presenting the user with 
information as to whether DNIS/Enhanced DNIS is active 
on the termination; the date that DNIS is activated; an 
indication of whether the Dialed Digit Outpulsing (DDO) is 
active on the termination; the prefix digits used for DNIS, 
and the number of digits to be reused for DNIS. Finally, an 
"International Outbound" tab (not shown) may be displayed 
for presenting the user with information as to whether 
international outbound is active on the termination; the 
Country code associated with the termination if international 
outbound is active; the Carrier code associated with the 
termination if international outbound is active; and the free 
phone number associated with the termination if interna- 
tional outbound is active. 

Via the TFNM Client Application, the user is now able to 
invoke TFNM functions such as the "IMPU'depicted in FIG. 
6 as the IMPL request 222 which enables the user to quickly 
change the number routing plan that a working number or set 
of working numbers is routing to; or "QUIK" depicted in 
FIG. 6 as the QUIK request 224 which enables the user to 
quickly add, change and/or delete one or more termination 
locations, and/or change the percentage allocation of two or 
more of these locations, for a currently implemented routing 
plan. In accordance with the present invention, additional 
directives may include: a temporary ("TEMP") IMPL direc- 
tive which is created in conjunction with an Implby entering 
a roll-back date so that the routing plan will revert to its prior 
use status prior to creation of the Impl; and a TEMP QUIK 
directive which enables roll-back of the changes made by a 
QUIK order to what they were before the QUIK. 

Referring back to FIG. 7, for the case when a user desires 
to implement the IMPL/TEMP IMPL plan, or the QUIK/ 
TEMP QUIK, the user selects the Setup IMPL from the 
TFNM screen at step 340. Specifically, the TFNM Client 
application causes the instantiation of an "Order Manager" 
object which invokes methods capable of accessing all the 
information pertaining to orders for a given corp id, set, 
TFNM telephone number and plan. An order comprises two 
components: 1) an order administration record comprising 
data such as: order status, effective data time and order 
number, etc.; and, 2) order administration detail record 
which includes the detailed information pertaining to that 
order, e.g., changes to percent allocation or effective dates/ 
times etc. for a plan, etc. The Order Manager object includes 
an ImplOrder sub -class which knows about IMPL orders, 
e.g., IMPL functionality, and invokes objects to obtain order 
records, pertaining to plans. As mentioned, an IMPL order 
allows a user to change which routing plan they want to be 
"in use" for a specific number or a set of numbers. 

FIG. 12 illustrates the IMPL dialog screen 255 enabling 
the user to generate a TEMP IMPL/IMPL order for the 
desired Corp Id. Particularly, as shown in FIG. 12, a number/ 
set selection dialog box 251 is displayed having radio 
buttons enabling selection of the desired 800/8xx Number, a 
set of numbers, a reserved number; or, an EVS Number for 
implementing an EVS plan. Selection of one of these will 
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invoke a "data controller" object for retrieving information tation. In view of FIG. 6, NetCap sends an acknowledgment 

from a TFNM database causing a corresponding dialog to via Registry messaging back to the TFNM server, 

appear enabling user search for the desired 800/8xx Number, Appendix B illustrates the Registry message calls that are 

set, reserved number, or EVS Number for the desired Corp transmitted to the TFNM server from NetCap in response to 

Id. After selecting the desired number or set, the user is 5 the submitted IMPL order. Included is the message indical- 

prompted to select from dialog box 252 the specific plan i^g successful processing of the IMPL request (NSUCS) and 

type that is to be IMPLM for the number or set. As shown, message indicating completion of the order in NetCap 

the dialog box 252 comprises radio buttons enabling user (UCOMP). The TPNM server passes this information on to 

selection of the desired plan IDs including, but not limited j^e user via CORMI messaging over the HTTPS connection. 

«nn/« M K ^ ^ ^ nnplemented for an ^^^^ ^ ^^^^ j ^ f acknowledgment appears 

800/8XX Number or a set of numbers, a Super Routing Plan *u • . ^ - i- 

(SRP) implemented for an 800/8xx NiJmber, a of ^"1;^^ ^'.f.T °° 1 ^''''T' '^t^T ^-^ ^u' 

numbers, or a reserved number; and, an EVS plan imple- ^2^ ^' ''f ^^"^3°^^? ""^^ TFNM retains the 

mented for an EVS Number. User selection of the plan is acknowledgment that the IMPL has been received and saved 

illustrated at step 345, FIG. 7. It should be understood that ^^e next user logon. Likewise, when an IMPL has been 

if the user has privileges for only one Corp ID, the system ^5 transmitted to NetCap and either implemented or 

will select only the plans associated with that Corp ID for the terminated, NetCap sends a registry message back to the 

user. If the user has privileges for more than one Corp ID, TFNM server which, in turn, passes this information back to 

the user is presented with a list of all Corp IDs and will select the user via HTTPS connectivity. 

one Corp ID. Any subsequent actions the user takes within Referring back to FIG. 7, at step 340, the user may instead 

the application are applicable to that selected corporation. 20 desire to execute the QUIK feature that enables customers to 

After having selected the Corp, set. Routing Plan Number quickly add, change and/or delete one or more termination 

or Routing Plan ID, the user may set or modify the routing locations (nodes), and/or change the percentage allocation of 

as indicated at step 350. In the preferred embodiment, the two or more of these locations, for a currently implemented 

user can define the routing plan according to any of the routing plan, FIG. 13 illustrates an exemplary web-page 

above -described options: Origin, Country, State, NPA, 25 screen 400 instantiated by the TFNM client application for 

NXX, Day of week, Time of day, and Termination, as the QUIL/TEMP QUIK order process which is presented to 

indicated at step 360. These options can be defined for each the user. As shown in FTG. 13, there is provided a number 

Corp ID, Set or number. In the preferred embodiment, the of radio buttons which the user may select: 1) an 800/8xx 

user is enabled to implement NLPs, SRPs, and EVSs and number button 402 which causes a dialog to be displayed for 

URPs for a selected toll free number or, implement NLPs 30 enabling the user to enter or select an 800/8xx number from 

and SRPs for a set of numbers that they want routed a list of 800/8xx #'s (not shown) having an associated "plan 

differently. Via IMPL request messaging, the user selects the in use." Once the 800/8xx # is entered, the system returns the 

desired routing plan for the number/set and the desired date corresponding NLP or SRP Plan in use; 2) an SRP button 

and time when they want to start routing the number to the 404 which causes a dialog to be displayed for enabling the 

selected plan and forwards the request to the TFKM server 35 user to enter or select an SRP Id from a list (not shown), 

via HTTPS messaging as indicated at step 355 (FIG. 7). Once entered, the system returns the SRP Routing Plan for 

As shown in FIG. 6, the customer's Send IMPL request the SRP Id; 3) an EVS button 406 which causes a dialog to 

222 is communicated over the HTTPS connection as a be displayed for enabling the user to enter or select an EVS 

request to invoke methods in the Order Manager class/sub- number. Once entered, the system returns an EVS Plan In 

classes via CORMI. Once the plan has been submitted to the 40 Use if available. In each dialog, a corresponding "data 

TFNM server via the send IMPL message 222, the TFNM controller^' object is invoked for retrieving information from 

server receives the new routing plan and verifies the user's a TFNM database causing a corresponding dialog to appear 

security with NetCap, as indicated at step 360 (FIG. 7). Once enabling user selection. 

the user's security has been verified, the TFNM server After selecting the desired plan, the user is required to key 

submits the IMPL request to NetCap 240 via Registry 45 or select each of the following buttons: Origination 

messaging, as indicated at step 365. Particularly, the Order Id/Description 407, Day of Week Id/Desc. 408, and Time 

Manager classes/sub-classes execute methods for translating Begin/Desc. 409. Selection of the Origination 

the IMPL order in a form suitable for submission to NetCap. Id/Description button 407 causes a list of Origination Id and 

Appendix A illustrates the Registry message calls that are corresponding descriptions to be displayed. In this manner a 

transmitted from the TFNM server to NetCap for the IMPL/ 50 user may scroll through the list and identify the branch 

TEMP IMPL order and the corresponding NetCap comprising the terminations that are to be modified, 

responses. Included is the message for submitting an IMPL Likewise, selection of the Day of Week Id/Desc. button 408 

order (NIMPL) to NetCap. causes a fist of Day of Week node ids/descriptions to be 

It should be understood that, in the case of a user displayed for the selected Origination Id node, and through 

implementing a TEMP IMPL request, the user follows the ss which the user may scroll through and select for modifica- 

same procedure as for the IMPL order, e.g., selecting the tion. Similarly, selection of the Time Begin button 409 

desired routing plan for the number/set and Corp Id. causes a list of Time of Day node ids/descriptions to be 

However, as shown in FIG. 12, the user is presented with a displayed for the selected DOW and through which the user 

dialog 253 for submitting the desired date and time when the may scroll through and select for modification. Through use 

user wants to start routing the number to the selected plan, 60 of the Order Manager classes/sub-classcs the system auto- 

and, a dialog 254 for submitting the roll back date and time populates the Orig, DOW, TOD, and, once populated, the 

when they want the previous routing plan to be effective system displays in display field 412 the Lterms for the TOD 

again. Thus, in accordance with the sequence of FIG. 7, both node which comprise the terminations and percent alloca- 

an IMPL and TEMP IMPL message pair is sent to the TFNM tions. In the preferred embodiment, the user may change 

server for processing as described herein. 65 percentage allocations by overtyping the amount or using 

After a TEMP IMPL and/or IMPL request has been the spin box up/down arrows 410 (increments of 1 percent), 

transmitted to NetCap 240, it is stored for future implemen- The user may additionally modify the percentages for the 
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remaining termination(s) as long as the sum of the percent- 
ages for all the terminations attached to the selected Time 
interval node equals 100 percent. Action keys 415o-415d 
may additionally be enabled for user selection in accordance 
with enterprise business rules and/or user security. 
Specifically, key 415a enables the submission of the QUIK/ 
TEMP QUIK order to NetCap for approval (Issue key). Key 
415/? allows the user to add a termination to the TOD node 
(including cross-coip terms that the customer has cross corp 
agreements with), or change the termination id, description, 
or percent allocated to the termination for this plan. 
Preferably, selection of key 4156 enables display of a web 
page having a Termination screen enabUng these choices. 
Key 415c enables the user to select the termination that the 
user wants replaced and presents the user with the Termi- 



10 



Appendix B also illustrates the Registry message calls 
that are transmitted to the TFNM server from NetCap in 
response to the submitted QUIK order. Included is the 
message indicating successful processing of the QUIK 
request (NSUCS) and the message indicating completion of 
the order in NetCap (UCOMP). The TFNM server then 
passes this information on to the user via CORMl messaging 
over the HTTPS connection. If the user is still logged on, 
this acknowledgment appears as a pop-up message on their 
screen, as indicated via line 226 in FIG. 6. If the user has 
logged off, TFNM retains the acknowledgment that the 
QUIK order has been received and saved for the next user 
logon. Likewise, when a QUIK has been transmitted to 
NetCap and either implemented or terminated, NetCap 



nation screen to select the term for change (Change Term ^5 sends a registry message back to the TFNM server which, in 

key). The key 415t/enables the user to select the term they turn, passes this information back to the user via CORMI. 

want to delete on the selected routing branch. In the pre- As described, a change to a routing plan is saved locally 

ferred embodiment, the system defaults effective date/time before being submitted to NetCap. The submission happens 

to the current date/time, however, the user may enter a future when the plan changes arc converted into an approved order 

rollback date/time up to 1 year in the data and time entry 20 having an approved order admin record and with a condition 



fields 416a, i) in FIG, 13. If the user enters a Rollback 
date/time in the rollback date fields, the system generates a 
TEMP QUIK order that sets the Routing Plan back to its 
state before the QUIK order. Preferably, the Rollback date/ 
time may not be greater than 1 year in the future. 

Thus, from the dialog box 400 (FIG. 13), the user is 
enabled to perform the following: 1) change one or more 
terminations for NLP or SRP; 2) replace one or more 
terminations on an EVS Routing Plan; 3) change the percent 



that NetCap has no preceding orders queued against the 
plan. The submission process takes place in two steps: first, 
the order admin record is seat to NetCap immediately, and 
second, when no orders are pending against the plan, the 
25 order admin detail record is then sent. The delay results 
because NetCap does not queue more than one order against 
a plan at a time. The TFNM server is configured to hide this 
limitation by stacking orders — a process of accepting mul- 
tiple submissions and queuing them internally for later 
allocationof currently implemented NLP, EVS, or SRP Plan; 30 transmission to NetCap. The order admin record is sent 
4) add one or more terminations to the currently imple- immediately. The order admin detail record is sent soon as 
mented NLP or SRP Plan; 5) add one or more terminations possible thereafter. 

to an EVS Routing Plan; and, 6) delete one or more Further functionality provided by the TFNM server is the 
terminations from the currently implemented plan of an ability to open plans, i.e., display a list of routing plans under 
NLP, EVS or SRP Plans. It should be understood that, in the 35 the current working environment for display as a VORT 
case of a user implementing a TEMP QUIK request, the user (FIG. 11), or, view orders and filter through orders, 
selects the desired routing plan for the number/set, the Particularly, the TFNM client will instantiate the Order 
desired date and time when they want to add, change and/or Manager object which instantiates order administration 
delete one or more termination locations and/or percentage detail objects and other objects for retrieving administrative 
allocation of these locations for a currently implemented 40 records comprising the details for a particular order in the 
routing plan, and, optionally, the roU back date and time TFNM database. For example, selection of the Report Order 
when the changes are to revert back to their original settings. menu option shown in the screen display of FIG. 9(c), will 
Thus, a QUIK and TEMP QUIK message pair is sent to the cause the display of an order filter screen enabling a user to 
TFNM server for processing as described herein, enter elements that they would like to use to query for orders 

Referring back to FIG. 6, the customer's Send QUIK 45 and submit order queries. The results of an order query arc 
request 224 is communicated by the TFNM client applet by displayed in an order select list 420, such as shown in FIG. 
communication between the Dispatcher server 235 and the 14. From this list, a user can retrieve details pertaining to an 
TFNM server objects using CORMI. The Object manager/ order, or, change an order's status or update remarks, 
sub -classes execute methods for translating the QUIK/ Particularly, from an administration button 422, the user is 
TEMP QUIK order in a form suitable for submission to 50 presented with a dialog 425 as shown in FIG. 15, for 



NetCap. 

Appendix A also illustrates the Registry message calls that 
are transmitted from the TFNM server to NetCap for the 
QUIK/TEMP QUIK order and the corresponding NetCap 
responses. Included is the message for submitting an QUIK 55 
order (NQUIK) to NetCap. 

Once the plan has been submitted to the TFNM server via 
the send QUIK message, the TFNM server receives the new 



example, enabling the user to update the order status and the 
effective date/time. It is from these dialogs that a user may 
select a button 423 to uo-approve an order (if the selected 
order has been approved by NetCap) and, a button 424 to 
"zap" (delete) an existing order. 

Appendix A illustrates the Registry message calls that are 
transmitted from the TFNM server to NetCap for 
un-approving an order (NOUAP), zapping an order 
(NOZAP), and, requesting pending order data (NPIUO). 



routing plan and verifies the user's security with NetCap. 

Once the user's security has been verified, the TFNM server 60 Corresponding NetCap responses are provided in Appendix 

submits the QUIK request to NetCap 240 via Registry B. 

messaging. It should be understood that, in accordance with the 

After a TEMP QUIK and/or QUIK request has been principles described herein, the TFNM management tool of 

transmitted to NetCap, it is stored for future implementation. the invention is capable of supporting "feature" orders, i.e., 

In view of FIG. 6, NetCap sends a registry message to the 65 functionality enabling customers to add a new TFN routing 

TFNM server acknowledging that the request has been plan, e.g., NLP, SRP, URP, or EVS, or, change other the 

stored. attributes or structure of an existing plan, e.g., changing 
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attributes of a routing plan directly from the VORT (FIG. 
11). The TFNM tool additionally may provide "drag and 
drop" enabling users to configure routing elements between 
plans. 

The foregoing merely illustrates the principles of the 
present invention. Those skilled in the art will be able to 
devise various modifications, which although not explicitly 
described or shown herein, embody the principles of the 
invention and are thus within its spirit and scope. For 
instance, although, the webAnternct network management 
tool described herein is described with respect to customer's 
toll-free, e.g., l-800/8xx networks, the principles may be 
readily applied to other types of telecommunications net- 
works. 

What is claimed is: 

1. An interactive Web/Internet based network manage- 
ment system for enabling configuration of a customer's 
telecommunications network via an integrated interface, 
said system comprising: 

a client browser application located at a client workstation 
for enabhng interactive Web based communications 
with said network management system, said client 
workstation identified with a ctistomer and providing 
said integrated interface; 

at least one secure server for managing client sessions 
over the Internet, said secure server supporting a secure 
connection enabling encrypted communication 
between said client browser appUcation and said secure 
server; 

a network configuration system for maintaining an inven- 
tory of a customer's telecommunications network call 
routing plans and associated plan details, and interfac- 
ing with network control elements for configuring a 
customer's telecommunications network according to a 
desired call routing plan; and, 

a network manager in communication with said secure 
server for receiving customer directives communicated 
over said secure connection via the client browser 
apphcation, said directives including a request to 
access call routing plan details according to a selected 
plan, and downloading said call routing plans details 
including a call routing tree to customers over said 
secure communications link for visual presentation at 
said client workstation. 

2. The interactive Web/Intemet based network manage- 
ment system as claimed in claim 1, wherein said client 
browser application enables customer modification of said 
call- routing plan details via said integrated interface and 
up -loading plan detail modification directives to said net- 
work manager over said secure connection, said network 
manager translating said received modification directives 
into commands for input to said network configuration 
system and forwarding said commands to said network 
configuration system. 

3. The interactive Web/Intemet based network manage- 
ment system as claimed in claim 2, wherein said customer 
request messages include unique customer identifiers 
enabling downloading of specific call routing plan details. 

4. The interactive Web/Intemet based network manage- 
ment system as claimed in claim 3, wherein said call routing 
plans pertain to a customer's toll-free call network, said 
unique customer identifier including a corporate identifier 
having one or more call routing plans associated therewith. 

5. The interactive Web/Intemet based network manage- 
ment system as claimed in claim 3, wherein said call routing 
plans pertain to a customer's toll-fi-ee call network, said 
unique customer identifier including a specific toll-free 
number having one or more call routing plans associated 
therewith. 
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6. The interactive Web/Interaet based network manage- 
ment system as claimed in claim 5, wherein modifiable call 
routing plan details include one selected from the group of: 
origin, country, state, day of week, time of day and 

5 termination, and any combination thereof. 

7. The interactive Web/Interaet based network manage- 
ment system as claimed in claim 2, wherein said customer 
directive includes an order to temporarily modify an exisdng 
network call routing plan for a predetermined period of time. 

8. The interactive Web/Interaet based network manage- 
ment system as claimed in claim 7, wherein said customer 
directive enables said call routing plan to automatically 
revert to a corresponding call routing plan configured prior 
to invocation of said directive, said directive including a 
revert date and time. 

9. The interactive Web/Interaet based network manage- 
ment system as claimed in claim 2, wherein said customer 
directive includes an order to temporarily modify a percent 
allocation of call trafiSc routed to a number tised in a 
particular routing plan. 

10. The interactive Web/Interaet based network manage- 
ment system as claimed in claim 9, wherein said customer 
directive enables said allocation of call traffic routed to a 
number to automatically revert to a corresponding percent 
allocation prior to invocation of said directive, said directive 
including a reverting date and time. 

11. The interactive Web/Interaet based network manage- 
ment system as claimed in claim 9, wherein said directives 
are communicated from said integrated interface over said 
secure connection to said network manager by a remote 
method invocation-like protocol. 

12. The interactive Web/Interaet based network manage- 
ment system as claimed in claim 2, wherein said client 
browser apphcation includes process for enabling construc- 

2^ tion of a new routing plan associated with a telephone 
number. 

13. The interactive Web/Intemet based network manage- 
ment system as claimed in claim 2, wherein said network 
manager further comprises process for verifying customer 
entitlements prior to downloading call routing plans details 
to said requesting customer. 

14. A Web/Internet based network management system 
for enabling configuration of a customer's telecommunica- 
tions network via an integrated interface, said system com- 

45 prising: 

a client browser application located at a client workstation 
for enabling interactive Web based communications 
with said network management system, said chent 
workstation identified with a customer and providing 

5Q said integrated interface; 

at least one secure server for managing chent sessions 
over the Internet, said secure server supporting a secure 
connection enabling encrypted communication 
between said browser client application and said secure 

55 server; and 

at least one secure server for managing client sessions 
over the Internet, said secure server supporting a secure 
connection enabling encrypted communication 
between a chent browser application located at a chent 

60 workstation and said secure server; and 

network manager for receiving customer directives com- 
mimicated over said secure communications fiiik, said 
directives including a request to access call routing plan 
information relating to a customer's network, said 

65 network manager downloading said call routing plan 
information including a call routing tree to customers 
over said secure connection. 



11/07/2003, EAST Version: 1.4,1 



us 6,5' 

25 

said client browser application enabling customer modi- 
fication of said call-routing plan information via said 
integrated interface and up -loading call routing plan 
modification directives to said network manager over 
said secure connection, 

whereby said customer's telecommunications network is 
thereafter configured according to said commands and 
modified call-routing plan details included therein, 

15. The interactive Web^nternet based network manage- 
ment system as claimed in claim 14, wherein said customer 
request messages include unique customer identifiers 
enabling downloading of specific call routing plan informa- 
tion. 

16. The interactive Web/Internet based network manage- 
ment system as claimed in claim 15, wherein said call 
routing plans pertain to a customer's toll-free call network, 
said unique customer identifier including a specific toll-free 
number having one or more call routing plans associated 
therewith. 

17. The interactive Web/Internet based network manage- 
ment system as claimed in claim 15, wherein said call 
routing plans pertain to a customer's toll-free call network, 
said unique customer identifier including a corporate iden- 
tifier having one or more call routing plans associated 
therewith. 

18. The interactive Web/Internet based network manage- 
ment system as claimed in claim 15, wherein said customer 
directive includes an order to temporarily modify a percent 
allocation of call traffic routed to a number used in a 
particular routing plan. 

19. The interactive Web/Internet based network manage- 
ment system as claimed in claim 18, wherein said customer 
directive enables said allocation of call traffic routed to a 
number to automatically revert to a corresponding percent 
allocation prior to invocation of said directive, said directive 
including a reverting date and time, 

20. The interactive Web/Internet based network manage- 
ment system as claimed in claim 14, wherein said customer 
directive includes an order to temporarily modify an existing 
network call routing plan for a predetermined period of time. 

21. The interactive Web/Internet based network manage- 
ment system as claimed in claim 20, wherein said customer 
directive enables said call routing plan to automatically 
revert to a corresponding call routing plan configured prior 
to invocation of said directive, said directive including a 
revert date and time. 

22. A method for remotely configuring a customer's 
telecommunications network via a Web/Interaet integrated 
interface, said integrated interface including a client browser 
application located at a client workstation for enabling 
interactive Web based communications between said cus- 
tomer and said integrated interface, said method comprising: 

managing a client session over the Web/Internet by pro- 
viding a first server device capable of supporting a first 
secure connection enabling encrypted communication 
between said browser application and said first server 
device; 

providing a second server device for communicating with 
said first server device through a firewall over a second 
socket connection, said first secure and second sockets 
forming a secure communications link; 

receiving customer directives communicated over said 
secure communications link, said directives including a 
request to access call routing plan information relating 
to a customer's network; 

downloading said call routing plan information including 
a call routing tree to customers over said secure com- 
munications link; and 
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modifying said call-routing plan information via said 
integrated interface and up-loading call routing plan 
modification directives to a network manager over said 
secure communications link, whereby said customer's 
s telecommunications network is thereafter configured 
according to said commands and modified call -routing 
plan details included therein. 

23. The method as claimed in claim 22, further including 
the step of enabling customer modification of said call- 

10 routing plan details via said integrated interface and 
up-loading plan modification directives over said secure 
communications link to a telecommunications network man- 
ager for receiving said directives, and translating said plan 
modification directives into a format capable of configuring 

15 said customer's telecommunications network, said modified 
call-routing plan details being forwarded to said interfacing 
system for configuring said customer's telecommunications 
network according to said modified call-routing plan details. 

24. The method as claimed in claim 23, wherein said 
20 customer directive includes an order to temporarily modify 

an existing network call routing plan for a predetermined 
period of time. 

25. The method as claimed in claim 24, wherein said 
customer directive enables said call routing plan to auto- 

25 matically revert to a corresponding call routing plan con- 
figured prior to invocation of said directive, said directive 
including a revert date and time. 

26. The method as claimed in claim 23, wherein said 
customer request messages include unique customer identi- 

30 fiers enabling downloading of specific call routing plan 
details. 

27. The method as claimed in claim 26, wherein said 
customer directive includes an order to temporarily modify 
a percent allocation of call traffic routed to a number used in 

35 a particular routing plan. 

28. The method as claimed in claim 27, wherein said 
customer directive enables said allocation of call traffic 
routed to a number to automatically revert to a correspond- 
ing percent allocation prior to invocation of said directive, 

AO said directive including a reverting date and time. 

29. The method as claimed in claim 28, wherein modifi- 
able call routing plan details include one selected from the 
group of: origin, country, state, day of week, time of day and 
termination, and any combination thereof. 

45 30. The method as claimed in claim 23, wherein said call 
routing plans pertain to a customer's toll-free call network, 
said unique customer identifier including a specific toll-free 
number having one or more call routing plans associated 
therewith. 

50 31. The method as claimed in claim 30, wherein said call 
routing plans pertain to a customer's toll-free call network, 
said unique customer identifier including a corporate iden- 
tifier having one or more call routing plans associated 
therewith. 

55 32. The method as claimed in claim 30, further including 
constructing a new toll free routing plan associated with a 
new toll free telephone number. 

33. The method as claimed in claim 22, wherein prior to 
said step of downloading said call routing plan and call 

60 routing plan details as response messages to customers, the 
step of verifying customer entitlements for accessing said 
call routing plans details. 

34. A method for remotely configuring a customer's 
telecommunications network via a Web/Internet based inte- 

65 grated interface, said integrated interface including a client 
browser application located at a client workstation for 
enabling interactive Web based communications between 
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said customer and said integrated interface, said method 
comprising: 

managing a client session over the Web/Internet by pro- 
viding a first server device capable of supporting a first 
secure socket connection enabling encrypted commu- ^ 
nication between said browser application and said first 
server device; 

providing a second server device for communicating with 
said first server device through a firewall over a second 
socket connection, said first secure and second sockets 
forming a sectire communications link; 

receiving customer directives communicated over said 
secure communications link, said directives including a 
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request to access call routing plan information relating 
to a customer's network; 
downloading said call routing plan information to cus- 
tomers over said secure communications link; and 

modifying said call-routing plan information via said 
integrated interface and up-loading call routing plan 
modification directives to a network manager over said 
secure communications link, whereby said ctistomer's 
telecommunications network is thereafter configured 
according to said commands and modified call -routing 
plan details included therein. 

4t ♦ )»: 4^ « 
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